Tile based rendering systems are known. These break down an image to be rendered into a plurality of rectangular blocks or tiles. The way in which this is done and the subsequent texturing and shading performed is shown schematically in FIG. 1. This shows a geometry-processing unit 2 that receives the image data from an application and transforms it into screen space using a well-known method. The data is then supplied to a tiling unit 4, which inserts the screen space geometry into lists for a set of defined rectangular regions, or tiles, 6. Each list contains primitives that exist wholly or partially in a sub-region of a screen (i.e. a tile). A list exists for every tile on the screen, although it should be borne in mind that some lists may have no data in them.
Data then passes tile by tile to a hidden surface removal unit 8 (HSR) which determines the visibility of each object by comparing the depth at each pixel in the object with the value currently stored in the depth buffer 14. If a pixel is determined to be visible the depth buffer is updated and the object tag passed to the pass spawn control unit 10 (PSCU). The PSCU updates the tag buffer 12 with visible tags from each object and passes them to the texturing and shading unit 16 (TSU) when it determines that a pass must be “spawned”. A pass is typically spawned when the PSCU attempts to write a tag for a translucent object into a tag buffer location that is already occupied. For a detailed description of the pass spawning process refer to patent 46009.GB01
The presence of the screen space geometry lists imposes an overhead on tile based rendering systems (TBR) that is not required in conventional immediate mode rendering (IMR) architectures. This overheard is typically dealt with by rendering the current scene and freeing the parameter memory used for subsequent primitives. This method has the disadvantage of requiring memory to be allocated for a full sized Z buffer in external memory. Further to this, if anti-aliasing is being applied to the scene then both the Z buffer and target render surfaces have to be at the full anti-aliased resolution i.e. if the scene is being rendered with 4× anti-aliasing with a target resolution of 512×512 then the Z and target surfaces must be allocated for 1024×1024 resolution. The use of high precision intermediate render targets that could otherwise remain on chip further compounds this problem. The net result is that one of the key advantages of a TBR system is removed by this approach.
The above approach also means that the entire memory used by a scene cannot be freed until it has been entirely rendered. This means that the system must either stall when waiting for a scene to complete or only allow half the memory resource be used in a single render so that tiling can continue during a render.
This situation is improved by a technique know as ‘Macro Tiling’ in which the screen is subdivided into a plurality of tiles which are then treated as rectangular groups of tiles or macro tiles. Object data is pointed to in per tile geometry lists as per normal tiling, however instead of a single ‘global’ list of objects each macro tile is given its own macro list. This allows memory to be allocated and freed on a macro tile granularity e.g. when all parameter space has been consumed, macro tiles are rendered to enable memory to be freed as opposed to rendering the whole scene. This mechanism minimises the amount of time the tiling and geometry processing hardware remains idle for in these circumstances, however it retains the same need for high resolution/precision Z and render target buffers to be allocated as above.